A typical background art “processor” system involves a processing module with processing instructions coded into the module. Typically, the process is comprised of the following steps:                A) Loading data from a data store into the module,        B) Signaling the module to process the data,        C) Exposing the results of the processing either by updating the run-time data or writing the results to a display, a data store, a printer output, or some other output representation.        
A well known enhancement the background art “processor” called a “processor with options” includes enhancing the processing module to accept optional parameters to alter the run-time behavior of the processing module.
A lesser known enhancement to the background art “processor with options” called a “configurable processor” includes enhancing the processor module to be comprised of very flexible and loosely-coupled processing instructions that can be executed, ignored, or executed repeatedly in arbitrary combinations. Which instructions are executed, how frequently, and in what sequence and combination is specified in a formation of data that is specified at edit-time and conforms to a specification that is interpretable by the “configurable processor” module. Those skilled in the art have called the technique used in a “configurable processor” Dynamic Object Technology, Agent-Based Heuristic technology, and Dynamic Algorithm Technology, among other names.
The “processor with options” typically supports a list of optional parameters sometimes called ‘flags’ or ‘switches’. A very simple example of a “processor with options” is the ‘xcopy’ module in a popular disk operating system. ‘xcopy’ can copy a file or a directory of files from one location on a computer storage medium to another. The ‘xcopy’ module is signaled to begin processing with a command such as:                “xcopy c:\rootdir\*.* c:\otherdir”.        
This indicates that the module should copy all files in “C:\rootdir\” and place the copies in “c:\otherdir\”.
The behavior of the ‘xcopy’ module can be altered with optional parameters. The ‘xcopy’ module can alternately be signaled with the command:                “xcopy c:\rootdir\*.* c:\otherdir\/D02-13-99”.        
This indicates that the module should only copy files in “C:\rootdir\” that were modified on or after Feb. 13, 1999 and place the copies in “c:\otherdir\”. The ‘xcopy’ module can furthermore be signaled with the command:                “xcopy c:\rootdir\*.* c:\otherdir\/D02-13-99/F”.        
This indicates that the module should only copy files in “C:\rootdir\” that were modified on or after Feb. 13, 1999, place the copies in “c:\otherdir\”. The “/F” option further indicates that ‘xcopy’ should display the names of the files as they are being copied. The ‘xcopy’ module supports nearly two dozen optional behaviors in this way.
This pattern of “processor with options” is useful where there is a relatively small number of optional behaviors available and where the optional behaviors are to be applied globally to the process. When more sophisticated behavioral control is required, the pattern quickly becomes unwieldy and a “configurable processor” is called for. For example if it is necessary to be able to specify different optional behaviors at different subdirectories a “processor with options” pattern command might look like:                “xcopy c:\rootdir\*.* c:\otherdir\/D02-13-99 /X-c:\rootdir\childdir D02-19-99 /X-c:\rootdir\otherchilddir D01-14-99/F”.        
This indicates that the module should copy files from “c:\rootdir\” to “c:\otherdir\”. Files in “c:\rootdir\childdir” should only be copied if they were modified after Feb. 19, 1999, Files in “c:\rootdir\otherchilddir” should only be copied if they were modified after Jan. 14, 1999, all other files should only be copied if they were modified after Feb. 13, 1999. Finally, the names of all copied files should be displayed as they are copied.
In this toy example, the configuration is still comprehensible and it is easy to see how the same results could be achieved by issuing multiple separate command signals. However, real production situations requiring a “configurable processor” typically make use of a large amount of configuration data that is difficult for a human to specify in a “processor with options” format. Furthermore, the behaviors are typically interdependent and cannot be broken into multiple distinct signals that are easier to manage.
A more effective and visual way of representing the command above might be:
1.xcopy c:\rootdir\*.* c:\otherdir\2./D02-13-993./F”4./X-c:\rootdir\childdir5.D02-19-996./X-c:\rootdir\otherchilddir7.D01-14-99
Where lines 1–7 represent configuration data with line 1 being the base directive for the “configurable processor”. Lines 2 and 3 represent optional configuration parameters for the base directive. Lines 4 and 6 represent additional localized directives and lines 5 and 7 represent optional configuration parameters of the 4 and 6 directives respectively.
Extrapolating from this example one can see that an appropriate and effective way to represent configuration data for a “configurable processor” is with a system of software objects. In the example, one Class of software object would represent a directive and a different Class of software object would represent an optional configuration parameter. Multiple directive objects and configuration parameter objects can be specified in a tree formation of arbitrary depth and breadth, allowing the user to exert great control over ‘xcopy’ operations. A real “configurable processor” might make use of dozens of different Classes of software objects in this way to support rich functionality that is very flexible and scales to a high degree of sophistication.
Restated, this technique facilitates the encapsulation of particles of functionality into a “configurable processor” which can be controlled with configuration data to exhibit a wide range of very sophisticated behaviors at runtime without the need change any source code.
In most cases a “configurable processor” requires configuration data to conform to a specification that it can interpret. This means that the configuration data must contain software objects that the “configurable processor” is aware of, and that the software objects must be connected with one another only in ways that the “configurable processor” is aware of.
Stated generally, for the universe of existing and unanticipated “configurable processors”, specific formations of edit-time configuration data consist of a network of software objects instantiated and connected in a way that conforms to a specification required by the “configurable processor”.
For non-trivial “configurable processors”, the number of allowable Classes of software objects and the constraints placed on their connections and values makes the specification of valid edit-time data formations very complex. A supportive editing environment is necessary for humans to be able to specify valid edit-time data formations effectively. Unfortunately, editing environments of this type are typically many times more effort-intensive to create than the “configurable processor” engines themselves. This dilemma hampers innovation and limits the value of using a “configurable processor” to automate a complex task.
What is needed is facility for specifying, editing, validating, managing, testing, and deploying formations of configuration data for a multiplicity of edit-time data models. This will have the benefit of reducing the total effort and cost of employing “configurable processors”.